

\documentclass[a4paper,12pt]{report}
\usepackage{graphicx }
\usepackage{hyperref }
\usepackage{multicol }
%% \usepackage{floatflt}
\usepackage[frenchb]{babel}
\usepackage[utf8]{inputenc}

\usepackage{makeidx}

%%micro... pr pdflatex
%% \usepackage{macroGraItal}

\usepackage{macrosAMoi}
\usepackage{amsmath} % Latex companion  p228
\usepackage{picture}
%\usepackage{dashline}
\usepackage{pstricks}


\usepackage{eepic}
\usepackage{epic}

%\usepackage{astron}

%\usepackage{chicago}

%changer affichage de biblio en + explicite


\title{rapport}

\author{  COULOMB,BARTHOLOME,TREGUER,MOUËZA}
\makeindex

\begin{document}
\maketitle



\part{bionic bootable build}
Pour la comparaison des répertoires linux-2.6.32 et AndroidSources, il faut bien se rappeler que la granularité n'est pas la même: linux est plus axé sur le noyau, alors que android contient un peu tout: noyau, périphérique, c'est plus le pendant GNU Linux. On s'appuiera sur nos notions de GNU Linux pour induire des déductions sur Androïd.
\chapter{bionic}
Ce terme fait penser aux extensions mécaniques et robotiques de l'Homme. Y-a-il un rapport.
``libc  libdl  libm  begin{verbatim}libstdc++ end{verbatim}  libthread\_db  linker'': ce sont principalement des bibliothèques pour développer en C,librairies partagées=dynamique,mathématique processeur dépendante,C++,parallèlisme,assenblage en exécutable ELF(donc compatible Linux) et librairies. 
Bionic semble être un nom quelconque, mais marque la spécificité par rapport aux bibliothèques POSIX GNU Linux : en  \cite{sitebio:0} 
\chapter{bootable}
\section{Notion de démarrage sous Linux}
En fait le démarrage est une succession de prise en charge de matériel et codes, de plus en plus importants au cours de la session car la reconnaissance est incrémentale basée sur la capacité du chaînon précédent \cite{wikBoot:0}. Pour nous, il est très important car c'est par lui qu'on pourra introduire notre textbf{scheduler} qui fonctionnera alors en autonome.
 Ainsi, à l'appui sur le bouton ON d'un PC, on passe par le mode Réel du processeur x86 \cite{wikBoot:0}   \cite{eldd:2007}  :
\begin{itemize}
\item le  \textbf{POST} qui  \textbf{teste} les différents matériels
\item le  \textbf{bootstrapping} avec entre autres le  \textbf{BIOS}( Basic Input/Output System) qui est une ROM qui teste le matériel non volatile comme les disques durs, carte PCI, lecteur de CD-ROM qui se trouvent à des adresses prédéfinies. Selon les matériels bootables et l'ordre de nos préférences, il \textbf{donne la main} au CD-ROM ou à des gestionnaires de démarrage de second niveau : GRUB, LILO, etc, selon les secteurs de boot(446octets) du Master Boot Record (MBR) en début de disque,suivi par notamment 64 pour une table de 4 partitions primaires maximum.
\item GRUB, LILO
Ce sont les démarreurs des disques durs implémentant GNU Linux. Ils chargent surtout les OS correspondant, et leur donnent la main: que ce soient des vrais systèmes avec noyau( avec certaines options) ou de simples programmes. Ils donnent eux-même la main au noyau en mode réel où on a accès qu'à 1MB de mémoire non protégée, où évidemment ce n'est pas le vrai noyau qui est chargé
\end{itemize}

On passe alors au mode protégé qui lance :
\begin{itemize}
\item le vrai noyau et des fonctions processeurs plus étendues comme la pagination. Le noyau devant s'appliquer au contenu d'un disque, pour pouvoir lire ses données(en EXT2,3,4,etc), il lance les premiers drivers disques spécifiques à la partition pour pouvoir la monter, grâce à initrd ou initramfs(la différence est une simple optimisation de la mémoire en taille, fragmentation, indépendance à un autre système de fichier).
\item init(), le père de tous les processus. C'est lui qui lance 
\item les processus utilisateurs et les démons: consoles, login.


\end{itemize} 

Après, pendant la session, le processeur peut passer :
\begin{itemize}
\item en mode noyau: il a alors tous les droits(processeur, noayau), mais doit avoir les droits root, car passer dans ce mode peut planter la machine, il faut donc des gens qui savent ce qu'ils font(codeurs du noyau, ou root). Autre grand avantage: ce code peut préempter d'autre code.
\item ou mode utilisateur: mode sécurisé où la machine n'est pas en péril.

\end{itemize}

Où intervient le scheduler?
\cite{eldd:2007}p257 : alors qu'on aurait pu croire que ça allait être une sorte de super processus à la priorité dynamique maximale 100 (\cite{undTlK:0} p260), ce n est pas un processus mais une simple fonction qui est appelée lors de chaque laps de temps slice, et qui traite les différentes listes par priorités.
\section{sous Androïd}
En gravant les CDs sous Linux, bootable fait plutôt penser à la section d'amorçage des CDs pour pouvoir démarrer une distribution au démarrage de l'ordinateur(POST i.e. Power On Self Test).
``bootable''n'est pas présent dans l'arbre Linux. 
En regardant la structure sous Androïd, on voit ``bootloader  diskinstaller  recovery''. Donc, notre première impression se voit confirmée.

Sur Linux, pour graver un CD-ROM, on utilise ``mkisofs'' et ``cdrecord'' , et ce qui le rend bootable:??. De prime abord, on peut se demander ce que les CD viennent faire là, sachant que les appareils Androïd sont soit des téléphones, soit des tablettes sans fonction de gravure. À cela, on répond que comme l'émulation préconisée par nous à partir d'un CD, si cette procédure marche, l'installation sur n'importe quel CD est censée fonctionner de fait sur n'importe quelle machine PC; d'autre part, c'est peut-être aussi du code emprunté à Linux pour une adoption de masse pour les machines sous Androïd. D'autre part, si on n'envisage pas encore beaucoup de PC sous Androïd, n'oublions pas aussi que les clés USB autres cartes Flash sont elles aussi bootables et plus envisageables car les tablesses proposent souvent des ports dédiés.
\section{démarrage Androïd sous émulateur} 
\chapter{build}
La création de quoi? Du noyau, comme ``xconfig ;make ;make install'' pour installer un noyau et ses modules?
Ce module se compose de ``core libs  target  tools''.

\begin{itemize}
\item core ne contient presque que des .mk, ce sont donc des directices de compilation
\item libs 
\item target désigne les cibles sur lesquelles intaller Androïd, avec ``board/generic'' pour des matériels generiques, sans noyau, traités par émulation, permetant une prise en charge de purs systèmes user, ces produits sont pour le moins exotiques(cf README.txt).
\item tools : différent utilitaires (bizarre le traitement des progragrammes Java par des .mk dans begin{verbatim}build/tools/droiddoc/src end{verbatim}au lieu de Ant). Par qui sont utilisés ces utilitaires?
\end{itemize}
\part{kernel}
\section{Modification du scheduler Androïd en RT}
En se contentant d'un simple RT, comme RM, il faut quand même \cite{hrtcs:11}  %\cite*{hrtcs:11}


\begin{itemize}
\item respect des échéances temporelles
\item bonne gestion de la montée en charge
\item si un pool de tâches doit être traité, le système doit dire à l'avance si c'est possible ou pas avant de se lancer dans des calculs, qui peuvent engager de gros risques: \textbf{prédictibilité}
\item le système doit être robuste et une tâche ne doit pas mettre en péril l'intégrité du système.
\item pour être facilement maintenable sans connaître parfaitement le système tout entier, le paradigme doit être basé sur le modulaire. 
\end{itemize}

Le noyau Androïd est-il CFS donc complexité O(1) avec le noyau 2.6?
En effet, pour respecter la prédictibilité,

\begin{itemize}
\item une connaissance parfaite du matériel(DMA,processeur) doit être requise, ce qui n'est jamais le cas dans la réalité.Certes ils permettent des accélérations, mais sont une source d'incertitude dommageable en situation critique.
\item une autre source d'indeterminisme est le comportement du gestionnaire de tâche lui-même: gestion des ressources,etc.
\end{itemize}
Pour être sûr de ne pas être ennuyé par des aléas, on se contentera de simples RM sans ressources.
Il vient: comment lancer la gestion de telle tâche? Comme sous GNU Linux, on peut lancer des tâches par un premier processus init. Et les redémarrages ne font pas de mal à la machine et sont rapides(voir ultra rapide: redémarage à la volée,sans boot) car on est en émulation.
\subsection{Notion de tâches}%search: tache,task   trace the execution of other processes (see the section "Execution Tracing" in Chapter 20). Table 3-4
Ce sont les entités qui seront traitées par le scheduler. On peut aussi dire processus ou par abus de langage, démons. La petite différence vient qu'en principe un démon reste toujours en arrière plan et n'interragit avec l'utilisateur qu'indirectement; on dit aussi des services(voire processus batch \cite{eldd:2007} p256), dont la santé est primordiale, c'est pourquoi ils sont eux-mêmes gérés par des super-serveurs (inetd,xinetd qui gèrent notamments les intérruptions par redémarrage automatique en cas de bug par exemple).
Si on regarde plus précisément un processus, c'est la donnée d'un descripteur de processus qui permettent au scheduler le gérer convenablement.
\cite{ undTlK:0} indique qu'il contient différents champs: state,thread\_info,usage flags,run\_list tasks,mm,real\_parent parent,tty,thread,fs,files,signal pending
%scheduler IO
\subsection{théorie}
Par une simple simulation hors-ligne des valeurs calculées par le scheduler
Le scheduler sous Linux
\subsection{pratique}
En introduidant des métriques(ps,graphique, moniteur système(notion de monitor?)) pendant que le scheduler est en situation.
Comme le chat de Schrödinger, ça change légèrement le comportement, mais peut être considéré comme négligeable, d'autant plus si ces métriques sont prises en compte par le scheduler et bien traitées(idéee de récursion: le scheduler doit traiter une entité qui le mesure lui-même?), et si les ``vraies tâches'' montent en charge, leur proportion de prise de processeur augmente(seuil critique?) 



\part{Questions légitimes}
En arrivant de GNU Linux, le nouvel arrivant pourrait se poser naturellement les questions:

\begin{itemize}
\item Comme sous Linux, il y a une console, et qu'en utilisant l'émulation Androïd on arrive sur un environnement graphique, a-t-on accès à une console sous Androïd.
\item Du même genre, a-t-on accès à un gestionnaire de processus, comme sous Linux avec ps?
 
\item /usr/bin /usr/sbin contiennent les principales commandes Linux, quelles sont les principales commandes sous Androïd?

\item Le topo donné donne un aperçu par répertoire, mais par exemple comment solliciter le répertoire /bootable/bootloader par exemple.

\item Un programme script Androïd est-il compatible Linux?

\item Y-a-t-il un server Xorg?

\item Peut-on installer Androïd sur un PC? Oui, l'utilisation par virtualiseur dinne exactement la même chose qu'on aurait à partir une installation normale,au niveau des fichiers sources, mais au niveau des ``fs'' filesystems = systèmes de fichiers le support passerait de iso9660 à ext4 par exemple de façon transparente par \textbf{vfs}=système de fichier virtuel. Cette virtualisation permet d'écrire indifférement des write/read pour des structures de fichiers support différentes. La seule grosse différence est qu'au lieu de rendre le CD-ROM bootable, on rend le disque dur bootable. 

\item Y-a-il un gestionnaire de packages?
\end{itemize}








\bibliographystyle{alpha} 
\bibliography{mabiblio}

\printindex 

\end{document}



